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Abstract — This paper presents a new rate based call gapping 
method. The main advantage is that it provides maximal through- 
put, priority handling and fairness for traffic classes without 
queues, unlike Token Bucket which provides only the first two 
or Weighted Fair Queuing that uses queues. 

The Token Bucket is used for call gapping because it has good 
throughput characteristics. For this reason we present a mixture 
of the two methods keeping the good properties of both. 

A mathematical model has been developed to support our 
proposal. It defines the three requirements and proves theorems 
about if they are satisfied with the different call gapping mech- 
anisms. Simulation, numerical results and statistical discussion 
are also presented to underpin the findings. 

I. Introduction 

There are many overload and load sharing problems to 
be solved in telecommunication networks of various kind 
e.g. in the Internet Multimedia Subsystem. Considering any 
type of network and signalling protocol a protocol operation 
flow consists of messages. The network nodes are entities 
receiving these messages and they process them using their 
resources such as CPU capacity or memory. In case they lack 
the resource to process the message we say that the node is 
overloaded. 

To avoid such situations the node itself can deny to serve 
the request and reject (send a negative reply message) or drop 
(ignore) it. Another solution can be that the sender (source) 
does not send out the message if for some reason it knows 
that the target will not be able to serve it. In both cases there 
is a decision logic deciding upon admission of the request or 
sending out the request (see Figure [TJ. This entity is called the 
throttle which is in the center of our interest. From now on 
we use the following terminology and model (see Figure 0. 
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Fig. 1. Schematic architecture of traditional external overload control 
mechanisms. The throttle entity is part of the source node. 

Definitions of the system elements and technical assump- 
tions for the model: 



Fig. 2. Schematic architecture of our model. The throttle is an individual 
functional entity. It can classify incoming offers and decides on admission or 
rejection of the offer. 



• The throttle decision function is a function mapping 
from the offer load point process to the set {admission, 
rejection). (Each throttle is uniquely assigned a function 
7 that transforms the intensity process p{t) of the in- 
come process to an intensity process of the admissions 
7 (p(f)) = a(t). @) 

• An offer is the event for which the throttle has to decide 
on admission or rejection. If an offer is admitted it cannot 
be rejected (dropped) and vice versa, and there is no third 
possibility. An offer has properties: arrival time, priority 
level and class which can be measured. 

• The traffic class and the priority level sets have finite 
elements. 

• The offered traffic (or offer load) is the flow of offers 
modeled with a progressively measurable not necessarily 
stationary point process marked with the marks from the 
mark space that is the direct product of the set of priorities 
and classes. (This implies that the probability of two offer 
events occurring at the same time is zero.) 

• The admitted traffic (or throughput) is the flow (i.e. the 
point process) of admitted offers (offers for which the 
throttle yields admission). The flow of admitted offers 
can be conditioned upon the whole history (past) of the 
offer load flow and upon the throttle parameters and of 
course on the decision strategy. 

The above assumptions and definitions are natural and 
obvious and also necessary to make the discussion clear. 

The throttle entity discussed here is one very important and 
well defined part of overload control systems of any type as it 
has the role to reject (or drop) an offer or to let it go through: 
admit it. The throttle realizes a call gapping mechanism if 
it makes the decision based only on previous offers i.e. no 
offers in the future are examined. This also means that in our 
case the non-anticipative throttle is not allowed to delay an 



offer and only one offer arrives at a time i.e. the call gapping 
mechanism cannot buffer the offer and admit it later than it has 
arrived. This makes a fundamental difference from Weighted 
Fair Queuing and mechanisms like those in (4), 0. 

Many call gapping mechanisms have been developed for 
different purposes with different characteristics. One of the 
most important call gapping algorithms is the Crawford algo- 
rithm [5]. It does not differentiate between incoming offers. 
One of the most common solutions that handles priority levels 
and some kind of traffic classes is the Token Bucket call 
gapping mechanism ifTTl . This one is also popular because 
it is also used to characterize telecommunication traffic JSJ. 

The aim here is to present a traffic estimation based call 
gapping mechanism that can provide traffic share Service 
Level Agreement, like weighted fair queuing mechanisms but 
without queuing the traffic. We discuss the following require- 
ments for a call gapping rate limiting throttle mechanism. 
The typical verbal definitions given here preliminary, are not 
precise and many contradict and can have multiple exact (i.e. 
mathematical) definitions with different results. 

• Requirement-A Maximal throughput with bound: No 
offer should be rejected if there is enough available 
capacity in the system to serve it, but no offer should 
be admitted if there is not enough available capacity to 
serve it in the system. 

• Requirement-B Priority levels: Each offer may be as- 
signed a priority level and the offer with higher priority 
shall be admitted in favor of the one with the lower 
priority level. 

• Requirement-C Throughput share for traffic classes: The 
offers can be classified and for the traffic class i the Si 
portion of the capacity of the target shall be provided. 

In this paper we give exact definitions of these requirements. 

In Section [II] we show how the Token Bucket mechanism 
meets Requirement-A and then for Requirement-B. Token 
Bucket does not fulfill Requirement-C. In Section [Til] our 
new method is presented. We give mathematical definitions 
of all the requirements and prove that our new method meets 
Requirement-A and Requirement-C. Then we present a call 
gapping method that is a mixture of the latter two and also 
show that it meets the requirements. In Section [IV] we present 
our simulations and some figures about the offer and admission 
traffic flows with the three mechanisms. Using statistics we 
show how each mechanism meets Requirement-B. 

II. Token Bucket Throttle 

We do not want to go into details discussing the throughput 
regulation properties of a Token Bucket algorithm (defined e.g. 
in patent [7] and used e.g. in standard [11]), but it is necessary 
to give a brief description to underpin the assumptions of our 
model. At first we present the concept of Token Bucket then 
show how it was extended to meet Requirement-B. 

A. The Token Bucket with parameters (r, W) 

The Token Bucket call gapping mechanism is the following: 
there is a bucket of available tokens representing available 



resources (free capacity) of the system. Requests are offered 
to the system and each of them is assigned a number of tokens 
needed i.e. the amount of resources it requires to be served. 
Once there are enough tokens in the bucket the request is 
admitted and dropped otherwise. (Thus no queues are applied 
and no delay is present in the system because of the Token 
Bucket call gapping algorithm.) 

By the definition of the original Token Bucket the tokens are 
generated into the bucket with exponential distribution and the 
offers arrive with a Poisson process in most models that means 
that the time interval between the arrivals is also exponentially 
distributed. We analyze and describe a variant of this. 

At first we mention that decision about serving a request are 
often implemented differently. The most important difference 
is in the interpretation: rather than consuming the tokens the 
bucket fill b is increased when a request arrives. The token 
generation is then realized with decreasing the bucket fill. The 
maximum fill is the watermark W that cannot be exceeded and 
also the bucket fill can not be lower than 0. This concept is 
equivalent to the original algorithm. 

Secondly we consider deterministic token generation instead 
of the exponential one that is used in most cases (e.g. ATI '), 
because it is much easier to implement and sometimes to 
analyze, as well. 

Then the Token Bucket mechanism we discuss works as 
follows: When a new request arrives at t n than the needed 
bucket fill is calculated: b(t n ) as if the request was served. 
This is done with calculating the expected number of tokens 
that would have been generated from the time the former 
service was served (t n _i) then multiply it with the throughput 
capacity of the bucket i.e. the Token Bucket rate at t n : r(t n ) 
and subtract it from the former bucket size at b{t n -\). Then 
it tests it against the preset constant watermark: W. 

Definition 1 (Token Bucket call gapping strategy 7t(r, W)). 
b(t n ) =max{x{t),b{t n -i)-r(t n - 1 )(t n -t n - 1 )+x(t)}, (1) 

where x(t) — 1 iff there is an offer. Admit if b(t n ) < W. If 
the offer is admitted, the above definition is used for the next 
value of the bucket fill b. If the offer is rejected, then b{t n ) is 
recalculated with x(t) = 0. 

(In many solutions the offers for the bucket can be of 
different types with different resource needs and thus SiXi(t) 
is used for update, where Sj is the so-called "splash amount" 
i.e. the expected number of tokens needed to serve the request 
of type i. From now on we suppose that Si = 1, since 
the calculations would be much more difficult without any 
qualitatively different result with respect to the requirements 
we consider now.) 

B. Priority handling with Token Bucket 

Once the offered traffic is modeled with a point process and 
the throttle meets Requirement-A we cannot provide priority 
between the offers. Why? Suppose that we have an offer in 
the system and we have to decide if we should admit it or 
not. Requirement-A tells us to admit the offer if we have 



the capacity to serve it. Suppose that this is the case and see 
that if the throttle would not admit the current offer to reserve 
this capacity for offers of higher priority then it might happen 
that there will be no higher priority offer in the future and the 
throttle would suffer a loss of workload. 

However, giving up the maximal throughput requirement 
some priority handling naturally can be done. In the Token 
Bucket concept different watermarks are assigned to each 
priority level. The offers of lower priority are checked with 
a lower watermark. This is kind of reserving a set of tokens 
(system resources) to the higher priority traffic. This method 
violates Requirement-A whenever b(t) declines to before 
rejecting an offer. Whenever this event has a low probability, 
using different watermarks for different priority levels is a 
good solution to meet Requirement-B with a Token Bucket 
throttle. 

III. Call gapping with rate estimation 

In this Section our new method, the proposed rate based 
call gapping throttle is presented. At first we introduce the 
complete proposed procedure clearly. Then we discuss and 
prove how it provides all the requirements and what possible 
extensions, modifications or other solutions might result a 
similar good algorithm. At the end of the discussion we present 
relationship between the new method and the original Token 
Bucket algorithm. 

A. The new call gapping algorithm 7 ff (c, T,g, s) 

Suppose that the consecutive offers arrive to the throttle 
at ... < <„_i < t n < t n+ i < ... time instants respectively. 
Each offer has a well defined priority level j, j 6 1..J and 
traffic class i 6 1../. Each priority level j has a constant 
priority parameter Tj assigned (Tj > Tk) if the offer with 
priority k has the higher priority) and each traffic class has 
a pre-configured weight i t— > Sj 6 (0, 1) C R, (where 

Si = 1). For each i the algorithm maintains an estimation 
of the incoming offer rate Pi(i), a provisional admission rate 
cti(t) from which it calculates a bounding rate gi(i) and then 
according to the decision it estimates an admission rate a,i(t). 

We suppose that the rate of the throttle varies with the 
following function: c(t). (This value is determined and given 
for the algorithm and represents the capacity of the throttle 
and might be different from r(t)). 

Definition 2 (The rate based call gapping 7 9 (c, T, g, s).). De- 
fine the proposed throttle decision strategy 7 9 in the following 
way. Suppose that at t n an offer arrives and the system is in 
state {t„_i, pi(t n ^i),ai(t n ^i)} and c(t n ): 

1) Determine priority constants, i.e. calculate Tj; 

2) Update the incoming rates estimate for all i: p(t n ) with 
Xk(t n ) — 1 iff i = k, otherwise; 

3) Calculate a provisional admission rate for all i: a(t n ) 
with Xk(t n ) = 1 iff i = h otherwise; 

4) Calculate the bounding rate for class i only: gi(t n ); 

5) If &i < gi then admit the offer and a(t n ) := a(t n ) else 
reject the offer and update a(t n ) with Xk(t) — 0,Vfc(7); 



6) ( Continue with 1. for the next event). 

We propose to update pi,cti,di according to the following 
equation: 

<H*n) ■= ~y~ +max{0, — }, 

where A is an estimator asymptotically unbiased for the \(t) 
real intensity of a point process thus to be replaced by 
Pi,6ii,a,i and indicator Xi(t n -i) = 1 iff the offer is of type i 
and otherwise (or further specified like in step 5). Note that 
the time parameter Tj changes in time too according to the 
priority level and the former one always has to be remembered. 

To calculate the bound rate at first we introduce u(f) the 
provisional used capacity according to Requirement-B: 

u(t) := ^min{s i c(t),/5 l (t)} (3) 

Pi(t)<Sic(t) Sic(t)<pi(t) 

Then the remaining (unused) capacity in the system is c(t) — 
u(t). This has to be split between traffic classes with higher 
incoming rate then the agreed share Pi(t) > Sjc(t). Then 

9l {t) := min{pi(t), 8ic(t) + {fc(t) °® ~ *ff }. (4) 

p-u(t) 

It is important to see that our method is capable to handle 
other class-wise throughput criteria than fair sharing and 
maximal throughput. Giving upper or lower bounds for g one 
can implement fairly complex throttle mechanisms. 

As one can see the new method is more complex than the 
original token bucket mechanism. However, the processing 
cost of updating the few variables introduced is significantly 
smaller than processing the offers thus does not count even in 
case of overload. 

B. 7 g meets all the requirements 

Now that the strategy is introduced we prove that it meets 
all the requirements. At first we define each requirement 
mathematically then we show how they are satisfied. We 
introduce some notation to make the discussion clear. 

• c(t) represents the true capacity of the system expressed 
in rate, i.e. some deterministic value coming from an 
external input source. 

• p(t) is the real intensity of the offered traffic and p(t) its 
estimate with ©. 

• a(t) is the real intensity of the admitted traffic and a(t) 
is the estimation of the rateintensity with (ffj. 

• a(t n ) is the preliminary admitted traffic intensity for 
which the following stands: a(t) — a(t),\/t < t n and 
a(t n ) is the intensity a(t n ) would have if the offer was 
admitted at time t n , and its estimate is a(t) accordingly. 



1) Requirement-A : This requirement consists of two parts. 
At first it says that there exists an upper bound for the system 
that should not be exceeded, i.e. it limits the admission rate to 
avoid overload. Secondly, it tells us that once the limit is not 
exceeded then all the offers should be admitted to maximize 
the utilization. However, in theory the words capacity and 
bound can have many different definitions depending on the 
model we use for the target node. 

The target node is often modeled with an inverse Token 
Bucket, i.e. server with deterministic serving rate s and a 
queue of maximal length Q. It is very easy to see that 
the Token Bucket throttle j t (s,Q) can perfectly meet the 
requirement in this case. (Note that this is true supposed that 
there is no delay in the system between the throttle and the 
protected entity while s(t) = r(t) is satisfied.) 

Another approach is to assume that the target can handle 
requests on a maximal call rate c that is used as the bound at 
the throttle. 

Both models have benefits and drawbacks while a mixture of 
them is used in practice. Speaking about the capacity of a node 
in Next Generation Networks engineers often refer the call rate 
value in industrial contracts and Service Level Agreements. It 
is very important to note that the feedback driven overload 
control mechanisms work with call rate information too (see 
ifTTl . On the other hand a server with queue is a common 
model in the academic literature for the CPU capacity and 
Token Bucket (or versions of it) is proposed in many standards 
(e.g. IfTTl again) and implemented into nodes. 

As a consequence we say that although it is rather difficult 
to give exact definition for Requirement-A we can give some 
definition grabbing a few properties depending on the method 
we use. 

Definition 3. Call rate bound. Requirement-A is met if 

E[ai(t n )] < c(t n ) (the throughput rate is bounded in 
expected value). 

Theorem 1. The throttle with strategy 7 g meets the call rate 
bound requirement. 

Proof: The proof relies on the fact that the estimator is 
asymptotically unbiased i.e. lirriT^ +oo E[a;Ti] = E[a,i] with 
negative bias if T > l/a^ (thus E[cii] < E[ai\). The proposed 
strategy j g limits a; so that ai < gi thus we are ready if we 
show that git) := Y^9i(t) = c(t). 

Define Ui(t) := £ i!ft(t)< , 4c(t) Pitt) and M*) ■= 
^i:s iC (t)<pi(t) S i c ( t ) thus u = u\ + u 2 and then = 
min{pi, SiC + (pi(t) — Sic(t))j^}. Although the system is 
non-stationary it is homogenous in time so f(t) — const, for 
all functions. Now calculate g(t))\ 

g = VV = Y] mm{pi, s,c + (pi - s, ; c)- — -} = 

= ^ + Sic+ (pi- Sic)- — - = 

. P — u 

i:pi<SiC i:SiC<Cpi 

C-Ux-U-2 

g = iti + u 2 + (p - ui - u 2 ) = c. (5) 

p — Ux — U2 



Corollary 1. The following calculation of g can also be used: 

9i (i) = min{ Pl , Si c(t) + (pi(t) - s i c(t)) C ®~'"® }, (6) 

P - u(t) 

where u(t) = Y^i;fcH)<sic(t) Pitt) = Then © becomes: 
g = ui + u 2 + (p - ui - u 2 ) = c. (7) 

p — Ul — U2 

The difference between the two strategies is that in case 
of g the remaining capacity is split between the classes with 
higher offer rates proportionally to their weights while using 
g' the remaining capacity is split proportionally the remaining 
offer rates. Both satisfies Requirement-A and as we will see 
Requirement-C. From now on g means either g or g 1 and the 
results will be the same obviously. 

2) Requirement-B: As pointed out before, the priority re- 
quirement for call gapping is the most complex in a way 
since in the gapping algorithms it is supposed that we make 
decisions using measures on the past and the present offer. 
No future events can be used thus Requirement-B is always 
satisfied. There is always one offer in the system and the 
throttle can admit or reject it according to Requirement-A 
and Requirement-B. 

In case of the Token Bucket call gapping different wa- 
termarks Wj are introduced for each priority level j. One 
interpretation is that the bucket allows larger peaks for traffics 
with higher priority thus Wj < Wk whenever k represents the 
higher priority level. Doing this, the bucket implicitly reduces 
the throughput for lower priority traffics (the extra peak in the 
bucket has to be refilled with tokens i.e. b(t) has to decline 
below the low watermarks to admit low priority traffic). Note 
that the different watermark levels has no effect if the offer 
rate is low with small peaks thus the rejection probability is 
small i.e. if there is no overload. Supposed that the true bound 
is W — max{Wj} this system preserves capacity for high 
priority traffic. 

We give a similar solution for the problem through the timer 
parameter of the estimators: T. As it was defined we introduce 
a function of T : j i— » Tj where 7\. < Tj if k represents 
the higher priority. (Note that it is the other way around for 
WjS.) The interpretation is that the estimator forgets the high 
offer rates faster for the traffic of the higher priority. Let 
T m = min{Tj}, the true bound on the throttle using different 
Tjs, means that for low priority traffic it remembers the high 
peaks for a longer period thus reserves capacity for the higher 
priorities similarly to the Token Bucket. 

The two methods have different characteristics, but one 
thing is common. Both reserve capacity for higher priority 
traffic. Now we say that to meet Requirement-B the system 
has to have this ability and define it in the following way. 

Definition 4 (Requirement on priorities.). Suppose that the 
throttle has rejected an offer at time t n -\. Let t n -j be the 
closest time the throttle is able to admit an offer of priority 



level j. Requirement-B is met iffVk, l(t n -k < t n -i) <^> (k > I) 
(k represents a higher priority). 

The exact proof of this statement is not ready yet. Sim- 
ulation result shows that the proposed strategy satisfies 
Requirement-B. We discuss the statement in the Numerical 
Results Section. 

3) Requirement-C: This is referred to as the throughput 
share requirement and tells us that there should be at least an 
Si portion of the capacity dedicated to traffic class i. 

Definition 5 (Requirement-C). The Minimum share re- 
quirement is met if Mi : (pi(t n ) < Sic(t)) =>- E[a,i(t n )] = 
Pi(t n ) i.e. if the offer rate of a traffic class is less than the 
agreed share it should be fully admitted. 

Theorem 2. The throttle with strategy -f g meets Requirement- 

C in expected value. 

Proof: At first we have the asymptotical unbiasedness 
for our estimators thus limy-, + oa E[a;T i \ — E[af\ thus the 
proof is true for the expected value of oj. 

Statement cii(t n ) = f>i{t n ) whenever Vipi(t n ) < Sic(t) is 
equivalent to the statement (gi(t n ) > &i(t n ) thus) gi(t n ) > 
&i(t n ) whenever pi(t n ) < Sjc(t). According to strategy 7 5 : 
gi(t n ) = Pi(t n ) whenever pi(t n ) < s,c(t) and since &i(t n ) < 
pi(t n ) because Oi(t n _i) < pi{t n -\), it is true that &i(t n ) < 
gi(t n ) thus the offer is admitted (and also &i(t n ) < gi(t n )). ■ 

C. Rate model for Token Bucket and a joint algorithm merging 
the methods 

In this section we introduce a model for Token Bucket that is 
equivalent to the definition in Section|lI]but makes calculations 
easier. 

Definition 6. Token Bucket Rate Model Strategy: jt ( r i W) Let 
us define T(t) — W/r(t) and use the following equation for 
updating the bucket rate variable: 

o(*n) = -jr- + max{0, } 

where x(t) — 1 iff there is an offer at time t. Admit the offer iff 
Q-{tn) < r(i n ). If the offer is admitted then the above definition 
is the used for the next value of the bucket rate variable a(t). 
If the offer is rejected then a(t n ) is recalculated with \{t) = 0. 

Theorem 3. The Token Bucket and the Token Bucket Rate 
Model Strategy are the same: 7 t = jf. 

Proof: It is easy to show that 6(t„_i) = a(t n _i)T 
b(t n ) = a(t n )T and the decision is b = Ta(t) < Tr(t) = W 
also trivial. ■ 
If one extends the Token Bucket for traffic class handling 
with some role like in the proposed mechanism it will not 
provide traffic class fairness. The reason is hidden in the 
fact that unlike p,a,a, {3 and all such estimators is not 
asymptotically unbiased i.e. E[X] = A as t — > + oo is not 



true for the estimators defined with: 

A(*nJ = -jr- + max{0, }. 

(8) 

The bucket fill does not represent at all the used capacity in 
the system it only measures the peakedness of the traffic but 
these peaks can happen on low offer rates too. 

On the other hand, the proposed method does not allow 
such big transient peaks in the traffic. Now we aim to make 
the proposed new call gapping to behave like Token Bucket. 
We define the following strategy that is a mixed architecture. 

Definition 7. Rate Based Call Gapping with Bucket-type 
Aggregate Characteristics: j x Take all the definition from 
the new call gapping mechanism "f g for p, a, a,u, gi and 
define Tj(t) = Wj/r(t). Take Wj and the bucket fill change 
definition b from the original token bucket 7 t . Perform all 
the steps like in j g but decide using the following constraint 
equation: ^^-a,i(t n ) < 9i(t n )- 

We will show numerically that the mixed algorithm behaves 
like Token Bucket on aggregate level and meets all the 
requirements. The source of the idea comes from the fact that 
a(t) places a strict bound on the rate thus a(t) < r(t) is always 
true as required. However we decrease the value of a and thus 
allow peaks in the traffic like Token Bucket does. (See that 
Token Bucket 7 t allows temporary bounding violation rate- 
wise unlike 7 g but like j x . The bucket size related to the 
whole bucket is a kind of measure of this violation.) 

1) "ft' and j x and Requirement-A : Here we discuss 
how the different algorithms meet the maximal throughput 
requirement. It is obvious that Token Bucket cannot meet 
Requirement-A in the way it was defined before since that 
definition assumed that the target has an infinite queue. 

We do not aim to give an exact definition to Requirement- 
A but we derive relations between the bucket and the estimator 
based throughput characteristics. The number of admitted 
offers i.e. the probability of admission is in the center of our 
interest. 

The probability of admission for token bucket depends on 
the offer rate with the following formula: 1 — Erlang[/>, r]. 
Thus the probability of losing calls is only defined at given 
values of p. 

For rate based call gapping, since the estimator always over- 
estimates the rate (A < A) and cuts the traffic strictly with c 
the admission rate is always below the target. But for the same 
reason it is possible that the offer is rejected although it could 
have been accepted according to the bound. The probability of 
this is the probability of estimating higher rate than c while the 
true offer rate is lower: P[a > c\a < c] = 1 — " P ^ a j ^j^ < ^ T ^ , 
where B[T] = 1/(T(1 - F[T}) + E[At\t < T]) — a is the 
bias. (Knowing the exact bias if constant intensity is supposed 
for the offer rate, the bound can be modified to have maximal 
throughput and strict bound at the same time.) 

The two methods can only be compared at a given value 
of the intensity. For all those values when the value of the 



intensity is not between c — B[T] and c the j g strategy 
works perfectly. The Token Bucket drops a call with positive 
probability for any value of the offer rate and also might admit 
when the intensity is higher than allowed. This means that we 
cannot tell which method is better or has the higher throughput 
since it depends very much on the offer rate. 

Theorem 4. The mixed strategy j x meets Requirement-A with 
appropriate watermark settings. 

Proof: It is shown in Theorem Q] that Y^9i(t) = g(t) = 
c{t) and since the definition of g was not changed we should 
only examine what means to compare gi to ^-a rather than 
to a. 

When we admit a request then 1 < b(t n ) < Wj < W max 
thus y^- — hi < i^-ai < ^r^fii < Sj. This tells us that j x 

lets through more messages than j g since E[ bi ^^ a,i] < E[ai\. 
Fortunately the maximal watermark limits this overflow error 
— - — E[ai] < £[ t ^ o i ]. It tells us that there is a setting of 
watermarks that guarantees bounding. (It is obvious that if 
Wm ax — » +00 then ^2 — q becomes very small and we 
always admit the request thus the theorem cannot be proved 
for any watermark settings.) ■ 

2) j x and Requirement-B: Some simple theorems are 
proved to show that the mixed strategy meets the priority and 
the throughput share requirements. 

Theorem 5. Token Bucket strategy j t meets Requirement-B. 

Proof: Obviously, the time to accept the next offer of 
priority level j is the time when the bucket level declines 
sufficiently to b(t) < Wj. For all levels k > j, Wk > Wj i.e. 
b(t) declines under the lower threshold later in time and the 
requirement is met. ■ 
Again it is rather hard to show that the mixed strategy 
-f x meets Requirement-B. However, it seems to be trivial 
that j x satisfies Requirement-B more drastically than 74 
does. We have interesting simulation results presented about 
this property. We can see numerical results about this in 
Section gVl 

3) "f x and Requirement-C: 

Theorem 6. The mixed strategy j x meets Requirement-C. 

Proof: As pointed out 7 X admits at least all the offers 
7 S does since Vi, < &i is compared to SjC while a 

comparison of a would be enough. This means that the 
mixed strategy provides minimum throughput share and fulfills 
Requirement-C. ■ 

IV. Numerical results and analysis 

Although we have nice proofs on the good behavior of 
the proposed rate based call gapping mechanism the complete 
mathematical discussion about the differences and similarities 
with Token Bucket is not ready yet. It is also true that 
the requirements can be interpreted with definitions slightly 
different from those we gave. Therefore we would like to 
present some simulation results and show that the findings 
are valid. 



The simulation is written in Mathemat- 
ica |[T3l and a notebook is available at 
http://www.math.bme.hu/ kovacsbe/rbcg/BENEDEK-KOVACS- 
rate-based-call-gapping-PRELIMINARY-VERSION.nb as an 
electronic appendix. 

A. Requirement-A 

The figures shows that all the mechanisms limit the admitted 
offer rate while try to keep the highest throughput. In this 
scenario we examine the traffic on aggregate level i.e. there 
is only one traffic class for which the capacity of the throttle 
should be maximized and limited. The capacity is 1 offer/sec 
for the simple simulation case while the average number of 
offers per sec raises from 0.8 to 2 meaning that there is a 
200% load on the node. 
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Fig. 3. The new algorithm (7 9 ) on aggregate level 

As it can be seen in Figure [3] all three mechanisms limit the 
admitted traffic although Token Bucket allows considerable 
peak at the beginning. (The size of the peak depends on the 
parameters we set. Here the 1 offer/sec capacity is very small 
compared to the watermark what is set to 10.) On the other 
hand, rate based call gapping seems to under-utilize the system 
while the joint mechanism seems to have the smoothest and 
also maximal throughput. 

After a total 600 offers from each traffic with the same exact 
trajectory the results shows that 7t,7 9 ,7 x has admitted 415, 
386, 404 number of calls respectively. 

The problem with the mathematical discussion of maximal 
throughput is that the results depend very much on the value 
of the offer rate and capacity. It is only possible to compare the 
mechanisms at given rates what is not available in the world. 

B. Requirement-B 

To discuss Requirement-B we provide the reader with 
some statistical results. The sample is generated with our 
simulation program. Generally there are two priority levels: 
normal and emergency calls. Each call is one of the two types 
with 1/2 probability. The means and the standard deviation are 
presented of 100 samples with 10 000 offers handled in each 
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TABLE I 

In each row the following quantities are presented 
respectively: total offer rate: p, maximal throughput: c, 

WATERMARK SETTINGS: WhIGHiT^LOW WHILE Tj := Wj/c. THEN 
PORTION IN REIECTED MESSAGES FOR TOKEN BUCKET, RATE BASED 
CALL GAPPING AND THE MIXED MECHANISM RESPECTIVELY. 



sample. The further setups for the simulation can be seen on 
Table HV-Bl 

It can be seen that all three methods reject less offer from 
those of higher priority but Token Bucket (j t ) and the mixed 
mechanisms (7^) enforce a more strict priority handling than 
the simple proposal. Note that in case of sustained overload 
(row 2) almost all dropped offers are the lower priority ones. 

C. Requirement-C 

The results tell explicitly that unlike the new rate based call 
gapping proposal the original Token Bucket algorithm does 
not meet Requirement-C. We consider a scenario when there 
are two traffic classes Class A and Class B. The agreed share 
for Class A is the 20% of the total capacity of the node while 
the share for Class B is the remaining 80%. The offer rates 
set for the simulator are exactly the inverse of this for the two 
type of traffic. 

The aggregate offer rate increases from 0.7 offers/sec to 
2 offers/sec and reaches the scenario of 100% overload (the 
capacity of the node is mean 1 offer/sec while the offered 
rate is a mean 2 offers/sec). The offer rate of traffic Class 
B is 0.4 i.e. it is still under its provided share thus all such 
calls are admitted. On the other hand the whole remaining 
capacity should be granted to traffic Class A and it should 
be admitted on a higher level than the agreed share and only 
those exceeding the capacity limit are to be rejected. 

Showing that the proposed method meets Req-C. 

Rale (message/sec) 
2.0 r 



1.5 - 




Fig. 4. The new algorithm (7 9 ) with two traffic classes. 



Showing that the Token Bucket does not meet Req-C. 
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Fig. 5. The special bucket algorithm that is not able to do meet any criteria 
because the bucket size has nothing to do with the offer and admission rates. 

Figure [4] shows how the behavior of the rate based call 
gapping mechanism while one can see the Token Bucket with 
exactly the same offered traffic on Figure [5] (In the simulation 
we also implemented a variant of Token Bucket that uses the 
A estimate and works like the Rate Based Call Gapping as 
mentioned in IIH-Cl but since the A estimate has nothing to do 
with the intensity of the traffic the result was the worst of all.) 

With the proposed mechanism the minimum share is guar- 
anteed for traffic Class B (the admission line is around the 
offered) while the requirement fails for Token Bucket. With 
the proposed method there is no rejected message of Class B 
since it never offers on a higher rate than the agreed share. 
The throughput of the throttle is limited but also maximized 
since Class A is granted all remaining capacity. 

V. Conclusions 

We have presented the "rate based call gapping" mechanism 
and its extension with the original Token Bucket mechanism. 
These unique mechanisms meet the maximal throughput with 
bound requirement, handle priorities and give minimum share 
for different traffic classes without using message buffers or 
queues. 

Examining the properties of the mechanisms we gave math- 
ematical definitions of the three requirements and accompa- 
nied the mathematical model with several theorems. Still the 
proof of priority handling is missing for the new methods, 
rather we have statistical analysis with the simulation we have 
coded to underpin our proposal and findings. 

Our rate based call gapping strategy can use different 
traffic intensity estimators. It is still an open question to 
find the optimal estimator or the optimal parameter setting of 
the estimators considering Poisson input traffic with variable 
intensity or even non-Poisson (e.g. general renewal or Hawkes 
type) input process. 

VI. Appendix 

Notations: 
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Watermark for Token Bucket 
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The token bucket throttle function 
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The rate based call gapping throttle function 
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The rate based call gapping throttle function 
with Token Bucket extension 
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